Object oriented programming based on an object model is a new way of programming computer programs that has become very popular over the past several years. Object oriented programming uses objects as its fundamental program building blocks rather than procedures as in conventional procedural programming. The focus of object-oriented program design is to define a set of autonomous entities that can work together. These autonomous entities are, of course, the objects.
Conceptually, an object has two parts, an external object interface and internal object data. Internal data is encapsulated by the object interface such that other objects must communicate with that object through its interface. Thus, the only way to retrieve, process or otherwise operate on the encapsulated data is through methods defined on the object. This protects the internal portion of the object from outside tampering. Additionally, because outside objects have no access to the internal implementation, that internal implementation can change without affecting other aspects of the program. The object system thus isolates the requestor of services (clients) from the providers of services (servers) by a well defined encapsulating interface.
Data in an object is operated upon by calling “methods” on the object. In the object model, a client object sends a call to the server object system. The call identifies a particular object and specifies what method is to be performed by the object, and provides any parameters required. The object interprets the message to decide what service to perform, and returns back any data that results.
Another central concept in object-oriented programming is the class. A class is a template that defines a type of object. A class is defined by a set of class parameters that specify the details of objects that belong to its class. By defining a class, objects can be created that belong to the class without having to rewrite the entire definition. This promotes the reusability of existing definitions and promotes efficient use of program code.
As already stated, object-oriented programming uses objects that interact with each other through method calls. These method calls are implemented by threads. For example, for an object A to interact with an object B, a thread first gets object A. While running within A's method the thread then gets object B and calls one of B's method. Thus, all parts of the interaction are performed by the same thread. This interaction is referred to as “A calls B.”.
There are many computer languages that support object-oriented programming. For example, Smalltalk, Object Pascal, C++ and Java are all programming languages that to one degree or another support object-oriented programming. Any of these and others can be used to write programs that use objects.
The Java language in particular has rapidly gained importance as a standard object-oriented programming language since its advent in late 1995. “Java” is a trademark of Sun Microsystems, Inc. Java programs (also known as Java class files) are converted from a well defined application program source code into an architecture-neutral, machine independent code, called Java bytecode. The Java bytecodes are designed to execute on a Java Virtual Machine (JVM). A JVM is not an actual hardware platform, but is a low level software emulator that can be implemented on many different computer processor architectures and under many different computer operating systems. Thus, the JVM is a virtual computer component that resides only in the memory of a computer platform.
A run-time class replacement facility for use in debugging Java programs during run-time provides the ability to substitute modified code in a running application through the debugger APIs. This feature of the Java Virtual Machine addresses issues such as vendors wanting the ability to do fix-and-continue debugging, i.e. while debugging, identify a problem, fix it, and continue debugging with fixed code, and organizations deploying long running servers wishing to be able to fix bugs without taking down the server. However, the ability to replace code in a running server in this way is not a specifically advertised use of the API. In fact, many JVMs either do not implement the API or do so only when running in a “non-production” mode due to the problems addressed by the present invention.
Sun Microsystems' Java programming language HotSwap Class File Replacement (HCR) feature comprises a useful part of Sun's Java Platform Debugger Architecture (JPDA). The JPDA is a specification document that describes debugging a JVM. The specification may be implemented by various computer programs, including Integrated Development Environments (IDEs). A Debugging tool (program) enables a software developer to debug a Java program whilst it is running on a JVM. The HCR feature of the JPDA allows a loaded class to be redefined through a call to the JVM. In the reference implementation, this functionality is implemented at the Java Virtual Machine Debug Interface (JVMDI) layer and made available through the higher layers of JPDA—the Java Debug Wire Protocol (JDWP) and the Java Debug Interface (JDI). International Business Machines (IBM) also provides a similar functionality called “Hot Code Replace” (HCR) for its “J9” JVM platform.
Debugging tools such as Sun's debugging tool known as the “Java Debugger” (“jdb”) are computer implemented and may be implemented through an IDE. An IDE is a programming environment that has been packaged as an application program, typically consisting of a code editor, a compiler or parser, a debugger and a graphical user interface (GUI) builder. The IDE may be a stand-alone application or it may be included as part of one or more existing and compatible applications. IDEs provide a user-friendly framework for writing, editing and debugging many modern object oriented programming languages.
Through debugging tools such as Sun's jdb and IBM's HCR for its J9 JVM platform, one or more classes may be redefined at run-time according to the new class definitions supplied. A program thread in the JVM may be actively executing a method that is being redefined by HCR. Such a thread need not be suspended for HCR to succeed because the JPDA specifies that in such cases threads continue to run the bytecodes of the previous version of the method. The redefined methods will be used on new invocations. HCR does not cause any initialization except that which would occur under the customary JVM semantics. In other words, redefining a class does not invoke its class initializers and no instance initializers or constructors are run. The values of pre-existing static variables will remain as they were prior to the call. However, completely un-initialized (new) static variables will be assigned their Java Language Specification (JLS) default values.
One drawback with current HCR functionality is that a redefined class (i.e. a piece of code replaced with a new version of said code) will only be used in execution once any existing execution of the old version of the code has completed. This is marked by an unwinding of the call stack of the application thread to a point past the scope of the code which was replaced. Due to the threaded nature of JVMs, multiple different threads can be executed simultaneously and a number of such threads can unwind sufficiently to pick up newly replaced code at different points in the execution of the application program. Consequently, the application program can run with a mixture of old and new code in different threads within the same application. Thus, there is a potential for conflict in the application semantics when some threads are running old code and others are running new code.
Furthermore, new code added at application program run-time can include a different data definition such as additional or fewer variables. Thus, any offset based data access will be jeopardized at run-time when such a code change is enacted. Further, any additional variables added at run-time in new code will be un-initialized and will rely on any language specific initialization for the application which is not ideal. It is invariably the case that the application requires application specific values and does not expect new variables to have their initial values set to their JLS default values.